Test262 conformance changes

Tested main commit: 50f0103d9188d33862efbc38397a81e497973632
Tested PR commit: a684036e5e486d0e3a29ab0ac5f19a58dba664b2
Compare commits: 50f0103...a684036

Codecov Report

❌ Patch coverage is 63.63636% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 59.46%. Comparing base (6ddc2b4) to head (a684036).
⚠️ Report is 886 commits behind head on main.

@@             Coverage Diff             @@
##             main    #5079       +/-   ##
===========================================
+ Coverage   47.24%   59.46%   +12.21%     
===========================================
  Files         476      582      +106     
  Lines       46892    63236    +16344     
===========================================
+ Hits        22154    37603    +15449     
- Misses      24738    25633      +895     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Done, pushed the fix. Makes sense to keep unfinished proposals gated, I should've caught that myself looking at how import.defer was handled :)

Quick question while I'm here: for the next PR I'm planning to wire up disposal into the exception handling path (try-finally integration + SuppressedError). Is there anything specific about how the current handler/finally mechanism works that I should be aware of before diving in, or is the existing try.rs in the bytecompiler a good enough starting point?

Yes, try.rs is half of the solution but the other half lives in https://github.com/boa-dev/boa/blob/main/core/engine/src/bytecompiler/jump_control.rs, which is our jump handler tracking code that ensures finally statements are always executed even when returning from functions or breaking from loops.

I imagine you can reuse the code that we have for try-finally to integrate using statements, since those are very similar in concept

Just went through both files. The picture is clearer now, jump_control.rs is basically the glue that makes sure any break, continue, or return inside a try block doesn't just jump past the finally. It does this by collecting JumpRecords and routing them through a JumpTable at the end of the finally block so each one ends up at the right destination after disposal runs.

For using, I think the approach would be: push a JumpControlInfo with TRY_WITH_FINALLY semantics when entering a block that has using declarations, wrap the block body in a handler (like push_handler does for try), and on exit emit DisposeResources in the same spot compile_finally_stmt runs today. That way breaks/returns/exceptions all naturally route through disposal before leaving the scope.

Does that sound like the right direction, or is there a cleaner way you had in mind :)